Telegram Group & Telegram Channel
Теперь немного подушним. За свою карьеру я-таки заметил одну вещь, от которой у меня пригорает. Многие разрабы не умеют в инкапсуляцию, от чего кишки классов и модулей часто вываливаются наружу.

Рассмотрим на примере. Представим что у нас есть вот такой класс:


class Disease {
var confirmed: Confirmed
}

enum class Confirmed {
YES, NO, NOT_SPECIFIED
}


Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
// какие-то проверки
this.confirmed = c
}


У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

Пример примитивный, но объём кучи навоза уже можно прикинуть. И многие разработчики не думают, как грамотнее инкапсулироваться, вываливают всё наружу, а потом жалуются, что у них всё слиплось.

Правильнее сделать примерно так:

fun confirm(){
// какие-то проверки
this.confirmed = Confirmed.YES
}

fun decline(){
// какие-то проверки
this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES


Методов больше, но зато внешний клиент знает меньше про устройство модуля, мы легко можем найти все вызовы без угадайки. К тому же светить Enum может оказаться совсем необязательным, ибо с точки зрения предметки нас интересует только факт подтвержденности диагноза, а что там внутри за статусы — вообще пофигу.

Но это ладно, когда мы знаем какой параметр передать, — это самый легкий случай. Иногда нужно знать последовательность вызовов или даже тайминг. Вообще, степень такой связности обозвали даже специальным словом Connascence.

Поэтому, когда вы пишете модуль, подумайте над следующим:
- Что вы можете скрыть и не показывать?
- Какие изменения внутри вашего модуля могут затронуть клиента?
Вы удивитесь, насколько проще клиенту будет работать с вашим модулем.



tg-me.com/stringconcat/226
Create:
Last Update:

Теперь немного подушним. За свою карьеру я-таки заметил одну вещь, от которой у меня пригорает. Многие разрабы не умеют в инкапсуляцию, от чего кишки классов и модулей часто вываливаются наружу.

Рассмотрим на примере. Представим что у нас есть вот такой класс:


class Disease {
var confirmed: Confirmed
}

enum class Confirmed {
YES, NO, NOT_SPECIFIED
}


Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
// какие-то проверки
this.confirmed = c
}


У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

Пример примитивный, но объём кучи навоза уже можно прикинуть. И многие разработчики не думают, как грамотнее инкапсулироваться, вываливают всё наружу, а потом жалуются, что у них всё слиплось.

Правильнее сделать примерно так:

fun confirm(){
// какие-то проверки
this.confirmed = Confirmed.YES
}

fun decline(){
// какие-то проверки
this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES


Методов больше, но зато внешний клиент знает меньше про устройство модуля, мы легко можем найти все вызовы без угадайки. К тому же светить Enum может оказаться совсем необязательным, ибо с точки зрения предметки нас интересует только факт подтвержденности диагноза, а что там внутри за статусы — вообще пофигу.

Но это ладно, когда мы знаем какой параметр передать, — это самый легкий случай. Иногда нужно знать последовательность вызовов или даже тайминг. Вообще, степень такой связности обозвали даже специальным словом Connascence.

Поэтому, когда вы пишете модуль, подумайте над следующим:
- Что вы можете скрыть и не показывать?
- Какие изменения внутри вашего модуля могут затронуть клиента?
Вы удивитесь, насколько проще клиенту будет работать с вашим модулем.

BY StringConcat - разработка без боли и сожалений


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/stringconcat/226

View MORE
Open in Telegram


StringConcat разработка без боли и сожалений Telegram | DID YOU KNOW?

Date: |

That strategy is the acquisition of a value-priced company by a growth company. Using the growth company's higher-priced stock for the acquisition can produce outsized revenue and earnings growth. Even better is the use of cash, particularly in a growth period when financial aggressiveness is accepted and even positively viewed.he key public rationale behind this strategy is synergy - the 1+1=3 view. In many cases, synergy does occur and is valuable. However, in other cases, particularly as the strategy gains popularity, it doesn't. Joining two different organizations, workforces and cultures is a challenge. Simply putting two separate organizations together necessarily creates disruptions and conflicts that can undermine both operations.

For some time, Mr. Durov and a few dozen staffers had no fixed headquarters, but rather traveled the world, setting up shop in one city after another, he told the Journal in 2016. The company now has its operational base in Dubai, though it says it doesn’t keep servers there.Mr. Durov maintains a yearslong friendship from his VK days with actor and tech investor Jared Leto, with whom he shares an ascetic lifestyle that eschews meat and alcohol.

StringConcat разработка без боли и сожалений from vn


Telegram StringConcat - разработка без боли и сожалений
FROM USA